Fix kanshi output names#4
Conversation
2. check $XDG_CONFIG_HOME before $HOME 3. all MAX SIZE now use platform-based macro from limits.h rather than magic number
Kanshi fails to match profiles when output descriptions contain parentheses like 'Iiyama North America PL2294H2 1207823601758 (DP-3)'. According to kanshi(5) manual, valid output criteria are: - Output names (e.g. 'DP-1') - Manufacturer/Model/Serial without parentheses This changes store.c to use head->name (e.g. 'DP-3') instead of head->description, making kanshi profiles work correctly. Fixes 'no profile matched' error when kanshi tries to apply configurations.
The match() function was still using the old quoted output syntax
("output \"%99[^\"]\"" pattern) which fails to match profiles
written with the new unquoted syntax (output DP-3).
This caused duplicate profiles to be created instead of updating
existing ones. Now supports both quoted (legacy) and unquoted
(current) output formats for backward compatibility.
* wip * Fix deprecated flag * check config path only on startup * use HEADS_MAX from wdisplays.h * remove useless strcpy * update readme and meson syntax * clang-format * Fix C23 issues gcc 15 is more strict and compiles C by default with C23. `noop` is used as a default null initializer, but now it must have the correct type, so add a cast. See also: https://bugs.gentoo.org/946954 --------- Co-authored-by: Viorel Munteanu <ceamac@gentoo.org>
* Add partial licensing header * add licensing info where needed * Update SPDX header in store.c --------- Co-authored-by: TanShaochang <30321432+petertheprocess@users.noreply.github.com>
|
@zipproth Could you rebase your patch on this branch? I tried merging it but cannot do so without rewriting the commit and losing its origin |
JasonGantner
force-pushed
the
v1.2.0-work
branch
from
b7b80b4 to
bcae16e
Compare
|
@JasonGantner I'm sorry for the delay – I missed the original GitHub notification from 6 months ago and only noticed when you closed this PR 3 days ago. To address your rebase request, I've created a new branch 'rebase-for-jason' in my repo, rebased on your 'v1.2.0-work', and pushed it. This should allow a clean merge without rewriting commits or losing origin. If you'd like to reopen this PR and update it to use the new branch, or if you prefer a new PR from my side, just let me know. I've also referenced this in my comment on petertheprocess#2, where I briefly touched on your suggestions (e.g., libscfg and separate include files). Thanks for your patience! Best, |
|
If you could re-open a PR with the new branch against I could then take care of a few things that are still needed before merging into
Other than that, I'd be happy to merge it and see where it goes. I also identified zipproth#1 and artizirk#33 as good candidates for new additions, but I'm unsure if they should be worked on in parallel. PS: sorry for the useless open/close notifications |
3 participants
No description provided.